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Abstract 

We consider zero knowledge interactive proofs in a richer, more realistic communication 
QL^ I environment. In this setting, one may simultaneously engage in many interactive proofs, and 

{^ • these proofs may take place in an asynchronous fashion. It is known that zero-knowledge is 

c/3 , not necessarily preserved in such an environment; we show that for a large class of proto- 

cols, it cannot be preserved. Any 4 round (computational) zero-knowledge interactive proof 
(or argument) for a non-trivial language L is not black-box simulatable in the asynchronous 
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Zero knowledge [ pO| ] turned out to be a useful tool for many cryptographic applications. Many 
works have studied the numerous uses of zero knowledge proofs, and many other works have 
O suggested how to improve the efficiency of these proofs. However, most of these works considered 
J> only the case where the proof stands alone, disconnected from the computing environment. An 
'k> ', interesting question, which naturally arises these days, is how robust the notion of zero knowledge 
^ is in a broader setting. In particular, many computers today are connected through networks (from 
small local area networks to the entire Internet) in which connections are maintained in parallel 
asynchronous sessions. It is common to find several connections (such as FTP, Telnet, An internet 
browser, etc.) running together on a single workstation. Can zero knowledge protocols be trusted 
in such an environment? 

The robustness of zero knowledge has been studied before in the "simple" case of parallel 
repetitions. It is often desirable to run a probabilistic protocol many times in parallel, usually 
in order to reduce the expected error of a single run. The alternative of running these protocols 
sequentially has a cost of increasing the number of rounds and is considered inefficient. It had 
been noted by several researchers that even in the parallel repetitions case the zero knowledge 
property does not necessarily hold. Goldreich and Krawczyk [|T^ proved a general lower bound: 
Any language that has a three round (black-box) zero-knowledge interactive proof with a small 
error probability (as can be obtained by parallel repetitions) is in BPP. Thus, for example, unless 
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Graph Isomorphism is in BPP, the protocol of [|T7]] for Graph Isomorphism does not remain zero 
knowledge when run many times in parallel. Several papers have dealt with this problem, usually 
by letting the verifier commit on it's (non- adaptive) questions in advance [|T], ^ |T5), [T^ ]. 

Our initial feeling was that the protocols that keep their zero knowledge property when run 
in parallel should also remain zero knowledge even in a multi- session asynchronous environment. 
However, in this paper, we give some indications that this is not always the case. 

Let us say a few words about what we need to show. In order to show that a protocol is zero 
knowledge in a modem networking environment, one must provide a proof that even within this 
complicated environment the protocol is still zero knowledge. But for us matters are simpler. We 
don't need to cover all facets of a networking environment. We only have to show that zero knowl- 
edge may fail in a specific setting that is part of this environment. Namely, the environment may 
be more hostile to the protocol than the specific case we study, but since a protocol fails even with 
a benign setting, it is definitely not zero knowledge when we extend the power of the environment. 
In particular, a networking environment may have various protocols running, multiple sessions, 
more than two parties involved, asynchronous setting, etc. 

We show that zero knowledge may fail for a large class of protocols, even if we only run 
a single protocol between only two parties. We exploit the asynchronicity and the existence of 
multiple sessions. Clearly, if we also add other features, such as additional parties and other 
protocols running in parallel, then the security problems can only be amplified. 

We show that any four-round black-box zero-knowledge proof with perfect completeness is not 
zero knowledge even in a very benign setting: The setting in which the protocol is run many times 
in an asynchronous environment, and an adversary (or the verifier) gets to choose which message 
gets to be delivered next. Actually, the setting is even more benign: We set a specific schedule, 
known in advance to both prover and verifier. Still, if the protocol can be (black-box) simulated, 
then the language must be in BPP. 

Theorem 1 Suppose that (P, V) is a 4-message interactive proof or argument for L with perfect 
completeness and error at most | and suppose that (P, V) can be black-box simulated in the 
asynchronous setting. Then L G BPP. 

The I in the above statement may be replaced by any constant less than 1, with essentially no 
change to our proofs; with slight care, any error bounded away from 1 by a non-negligible factor 
may be accommodated. 

The above result holds for all extensions of concurrent zero-knowledge. In particular, it holds 
for resettable zero-knowledge ^. 

Note that we get a separation between protocols that remain zero knowledge even under parallel 
repetition and protocols that remain zero knowledge in an asynchronous setting. Assuming the 
existence of one-to-one one-way functions, there exist 4-message (computational) zero knowledge 
arguments for all NP languages [IT^. However, there are no 4-message zero knowledge arguments 



for languages outside of BVP that are black box simulatable in the asynchronous setting. 

Some words on the terminology we are using. By zero knowledge we mean computational zero 
knowledge, i.e., the distribution output by the simulation is polynomial-time indistinguishable from 
the distribution of the views of the verifier in the original interaction. (Of-course, as the result is a 
lower bound, it holds also for perfect and statistical zero knowledge.) The prover may be infinitely 
powerful (i.e., an interactive proof) or it may be computationally bounded (i.e., an argument). We 
consider black box zero knowledge as defined by Goldreich and Oren [^ [1^, and refined in [[T^. 



1.1 Related work 

Dwork, Naor, and Sahai [ [T0| ] were the first to explore zero-knowledge in the asynchronous setting. 
They denoted zero-knowledge protocols that are robust to asynchronous composition concurrent 
zero-knowledge protocols. It was noticed in [[T^] that several known zero-knowledge proofs, with 
a straightforward adaptation of their original simulation to the asynchronous environment, may 
cause the simulator to work exponential time. Thus, it seems that the zero-knowledge property 
does not necessarily carry over to the asynchronous setting. In order to provide a protocol that 
may be used in a modern environment, they presented a compromise: a protocol that is not zero- 
knowledge in a fully asynchronous setting, but is zero-knowledge in an environment with bounds 
on the asynchronisity. In particular, they present a 4 round zero-knowledge argument for NP 
assuming that there are two constants a and (3 such that the fastest message arrives within time at 
least a and the slowest message arrives within time at most (3. 

Dwork and Sahai [[Tl|] reduced the limitation on the asynchronisity. They presented a proof 
which has a preprocessing phase and a proof-body phase. Their proof is concurrent zero-knowledge 
argument for NP such that the (a, (3) limitation is required only during the preprocessing stage. 
Then, the body of the proofs can be run in a fully asynchronous environment. 

Our result is complementary to theirs, illustrating why it is difficult to achieve zero-knowledge 
in the asynchronous setting without using such an augmented model. 



Several subsequent works have already appeared since the first publication of this paper [gSp. 
One question that was raised was: does there exist a fully asynchronous (concurrent) zero-knowledge 
proof for NP? 



The answer was given by Richardson and Kilian pSQ who presented concurrent zero-knowledge 
arguments for all languages in NP, that is robust in the fully asynchronous setting. However, this 
protocol is not practical. It requires a polynomial number in k of rounds, which makes it unaccept- 
able in practice, k here is the security parameter: the length of the input and the number of proofs 
that may run concurrently are bounded by a polynomial in k. 

The upper bound on the number of rounds has been drastically improved by Kilian and Petrank 



[ p2| ] . It turns out that the number of rounds that suffices for constructing concurrent zero knowledge 
is any m satisfying m = a;(log^ k). 

Rosen p^ has improved the result described in this paper, i.e., the lower bound on the number 
of rounds required for concurrent zero-knowledge from 5 to 8. Canetti, Kilian, Petrank and Rosen 
[^ have substantially improved the lower bound to r2(log'^ /loglog A;). The parameter k is the 
security parameter. A polynomial in k bounds the length of the inputs, the number of proofs that 
may start concurrently, and the time complexity that the parties spend in the protocol. 

Other researchers have concentrated on presenting efficient concurrent zero-knowledge pro- 
tocols for NP with weaker compromises on the asynchronisity of the environment. Crescenzo 
and Ostrovsky [|Sp presented a concurrent zero-knowledge argument for NP with a preprocessing 
phase. They removed the (a, (3) constraint of [[TTI], and the only requirement is that there must be 
a separating point in time between all preprocessing of all concurrent proofs, and all bodies of all 
proofs. Namely, the first body of any proof may start only after all preprocessing phases in all the 
proofs have completed. Damgard [^ and Canetti et. al. [^ have further reduced the limits on 
asynchronisity. They require that prior to the beginning of the proofs, all verifiers have deposited a 
public key in a public database. In [j^] it is required that the public key is valid, i.e., that the verifier 
must know the secret key associated with it. In [j^] this requirement is relaxed. The verifier only 
has to have a deposited string in the public database. Thus, these proofs are efficient, and make 



only the following compromise over full asynchronisity: all verifiers must be previously registered 
before any of them can engage in a proof. A verifier that has not been registered cannot join until 
all proofs are completed and then it must register itself before any new proof begins. 

As an extension to concurrent zero-knowledge, Canetti et. al. presented resettable zero- 
knowledge proofs [^. These are zero-knowledge proofs that on top of being concurrent, they 
remain zero-knowledge also when the verifier is allowed to run the prover repeatedly on a fixed 
(yet, randomly chosen) random tape. Our lower bound applies, of-course, also to resettable zero- 
knowledge. 

Feige and Shamir have suggested to give up achieving full zero-knowledge in the asynchronous 
setting and presented a property of proofs called witness indistinguishability. They showed that 
witness indistinguishability is preserved also in the asynchronous setting [JTSj]. 

The basic framework of the proof in this paper uses the ideas developed by Goldreich and 
Krawczyk [[T^. Following their technique, we use a good simulator S of an interactive proof 
(or argument) (P, V) for a language L to create an efficient prover Ps that causes V to accept 
reasonably often on inputs in L. 

1.2 Guide to the paper 

In Section]^ we discuss black-box simulatability and the framework used by Goldreich and Krawczyk. 
In Section |] we show how to convert an asynchronous simulator into an efficient prover. In Sec- 
tions and H we analyze the success probability of this prover. 

2 Preliminaries 

2.1 Black-Box Zero-Knowledge 



The initial definition of zero-knowledge [|19|] required that for any probabilistic polynomial time 
verifier V, a simulator Sy exists that could simulate V's view. Goldreich and Oren [|2^, [TSp pro- 
pose a seemingly stronger, "better behaved" notion of zero-knowledge, known as black-box zero- 
knowledge. The basic idea behind black box zero-knowledge is that instead of having a new simu- 
lator Sy for each possible verifier, we have a single probabilistic polynomial time simulator S that 
interacts with each possible V . Furthermore, S is not allowed to examine the internals of V , but 
must simply look at y's input/output behavior. That is, it can have conversations with V and use 
these conversations to generate a simulation of V's view that is computationally indistinguishable 
from V^'s view of its interaction with P. 

More formally, Goldreich and Krawczyk give the following version of this definition (notation 
changed for compatibility with our own), which avoids certain trivial problems in the original 
expositions. 

Definition 1 (/|76|/, following / |2^ |7^j An interactive proof (P, V") is called black-box simulation 
zero-knowledge if for every polynomial p, there exists a probabilistic expected polynomial time 
oracle machine Sp such that for any polynomial size verifier V that uses at mostp{n) random coins 
on inputs of length n, and for x E L, the distributions (P, V){x) and Mp{x) are polynomially 
indistinguishable. 



Remarks: In the above definition, V may be thought of as a circuit (pedantically, a circuit family) 
that has access to random bits. The size of V refers to V^'s circuit size. It follows that V runs 
in polynomial time, which is necessary for a meaningful notion of computational zero knowledge, 
though not for statistical and perfect zero knowledge. By polynomially indistinguishable, we infor- 
mally mean that no computationally bounded distinguisher can, for some constant c and infinitely 
many x E L, correctly guess whether a random sample came from (P, V) (x) or Sp{x) with prob- 
ability greater than | + l/lxj'^. For statistical and perfect zero knowledge, we allow for unbounded 
distinguisher; equivalently, we require that the statistical difference between the distribution be 
negligible (less than l/lxl"^ for any c). 

The above definition requires the existence of a single universal simulator, S, for all possible 
(efficient) verifiers. At first glance, the limitations on S may seem to force S to be as powerful as a 
prover. However, S has important advantages over a prover P, allowing it to perform simulations 
in probabilistic polynomial time. First, it may set V's coin tosses as it wishes, and even run V 
on different sets of coin tosses. More importantly, S may conceptually "back up" V to an earlier 
point in the conversation, and make different statements. This ability derives from S"s control of 
V's coin tosses; since V otherwise operates deterministically, S can rerun it from the beginning, 
exploring different branches of the conversation tree. 

Indeed, all known proofs of zero-knowledge construct black-box simulations. There is no 
way known to make use of a verifier's internal state, nor to customize simulators based on the 
description of V other than by using it as a black box.[] Thus, given the current state of the art, an 
impossibility result for black-box zero-knowledge seems to preclude a positive result for the older 
definitions of zero-knowledge. 

2.2 Black-box verifiers with private random functions 

In this paper, as in [[T6|], we note that it is enough to consider deterministic V, i.e., even determin- 
istic (yet, cheating) verifiers are hard to simulate. Also, following [|T^, we consider verifiers V 
that have access to a private random hash function H, that is wired into them and is not directly 
accessible to the simulator (note that V is deterministic in that it doesn't use an external source of 
randomness; its construction is randomized). That is, the simulator may gain only indirect access 
to H, by observing V's input/output behavior. For convenience, we assume that for any polyno- 
mially bounded n and m, H will take an n-bit input and return an m-bit output. In practice, H 
will be defined for big enough n and m, and its inputs (if short) will be padded to fit the length of 
H's, inputs. Pedantically, we can view H as a family {iJ,„ „} of hash functions; we suppress these 
subscripts for clarity. 

As in [|T^, we will think of H as being randomly chosen from a family of hash functions [{7p. 
And as in [|T^ we do not use the standard pairwise independent family. Instead we use families 
of hash functions that achieve ]9(n)-independence, for some sufficiently large polynomial p. A 
member H in this family can be described by a string of polynomial length, and it is this string 
that is wired into the verifier. The polynomial p is set to exceed the running time of the simulator 
times the length of V's answers. Thus, even if the simulator poses to V a different query in each of 
its steps, and if for each query V generates the hash of the query, using H, then the simulator will 
face a verifier that uses a completely random string for each of its (different) queries. Of course. 



^As one slight exception, [ETJ proves security against space-bounded verifiers by considering the internal state of 
the verifiers. However, these techniques do not seem applicable to more standard classes of verifiers. 



if the simulator repeats a query, then the "deterministic" V repeats the same response. Our use of 
the hash function will be as follows. The deterministic V will invoke the honest V with a random 
tape determined by a hash on the history of the interaction so far (a history from interactions that 
do not involve V and do not influence V's, actions normally). Thus, although V is deterministic, 
the hash of the history so far will give it the randomness that will foil the simulation. 

We remark that the specification of H need not be a long polynomial string as assumed in the 
analysis. Instead, one may use a short seed and use a pseudo-random generator to choose a random 
H from the family of hash functions. This does not change the probability of failure for the prover 
we build by more than a negligible fraction. 

2.3 Restricted interactive proofs 

In this paper, we consider interactive proofs in which it is possible to tell whether V will accept 
based on its conversation, without looking at its random coins. All the proofs we are aware of have 
this "conversation-based" property. The theorem is also correct without making this assumption. 
However, showing the theorem without the assumption requires a longer and more complicated 
proof. We feel that this complication is of small interest and we do not include it in the paper. 

3 Creating an efficient prover 

To prove our main theorem, we construct a particular malicious verifier (pedantically a family of 
closely related malicious verifiers), with a fixed scheduling strategy (a very similar strategy is used 
in [[ro|]). We show that a simulator that successfully simulates the multi-conversation on input x 
with high probability can be converted to a probabilistic polynomial prover Ps for the original 
protocol. This prover will cause V to accept x with probability strictly greater than 1/2. Thus, we 
can use this prover to probabilistically decide whether x e L, implying that L E BPP. 

3.1 The attack 

Let the original protocol consist of an initial challenge q, followed by a reply, r and a second 
challenge, s and a final reply t. The honest verifier V generates g as a function q{x, R) of the 
input and its random coin flips, R. V generates s as a function s{x,R,r) of the input, R and 
r (g is implicit given x and R). Finally, V computes a predicate accept(x, q, r, s, t) to determine 
whether to accept or reject. Note that this restricts the acceptance predicate to being "conversation- 
based," in which one can tell whether V will accept based on its conversation, without looking at 



its random coins. As mentioned in Section ^3| we prove our result with respect to such interactive 
proofs. 

Let k and m be parameters that will be chosen later. (Both polynomial in the length of the 
input.) We consider the protocol obtained by performing m proofs in parallel. Thus, we denote the 
initial challenge by 

g=(g\...,g-) = (g(x,i?i),...,g(x,i?'")), 

where R = {R , . . . , R"^). We define r, s and t analogously. Finally, we define accept{x, q, r, s, t) 
to be true iff accept(x, q\ r\ s\ f) for alH, 1 < i < m. We call such a parallel set of proofs an 
m-block. 



Note that parallel repetition is a special case of scheduling in an asynchronous environment. We 
remark that parallel repetitions reduce the error probability for interactive proofs but not necessarily 
for arguments (see [^). ^From now and on, we always use parallel repetitions, i.e., m-blocks 
proofs, instead of running a single message in each round. 

Our attacking verifier V is defined by the value of its private random hash function, H and 
parameters k and m. V runs a total of k m-block-proofs with the prover. We use subscripts to 
denote the version, e.g., q' denotes the first question in the zth run of the protocol. (Remember 
that these are actually m parallel first questions.) The verifier interleaves its challenges so that the 
sequence of messages appears as 

— * — * — * 

^l,n, (h, ^2, . . . , Qk, Tfc, Sfc, tfc, Sfc_i, tfc_i, . . . , Si, ti. 

In the rest of the paper we fix this specific schedule, and assume the interaction is according to this 
schedule. Thus, our lower bound is valid even if the schedule is statically fixed and known to the 
simulator. The adversarial verifier V invokes the honest verifier V for each of the proofs. However, 
the random tapes of the honest verifier are determined using the hash function, by 

Ri = H{x,qi,fi,...,qi_i,fi_i). (1) 

Namely, it is the output of the hash function on the history of the interaction (of all concurrent 
proofs) so far. We assume that H returns the correct number of random bits used by V. (In 
particular, m random strings are required for each of the blocks.) The questions gj and Si are 
defined by: g^ = g(x, Ri) and Sj = s{x, Rj, fi). However, if for any i, accept{x, qi, fi, Si, tj) does 
not hold, then V aborts immediately, without sending Sj_i, . . . , si to the prover. 
We can thus view a conversation as consisting of two phases. The generation of 

gi,n,g2,r2,...,gfc 

constitutes the creation phase, in which new blocks (values for Ri) are created by V, and the 
generation of 

^k, Sk, tk, Sk-l, tk-l, . . . ,Si,ti 

constitutes the resolution phase, in which these proofs run their course. We treat these phases quite 
differently when discussing the simulator. 

Note that all the randomness used by V as invoked by V comes from H. In particular, V is 
deterministic and doesn't use its random input, to some extent limiting the simulator 5"s power 
over it. 

3.2 The simulator 

Our proof is by contradiction: assuming a simulator S that properly handles our adversarial verifier 

V we construct an efficient prover Ps- The prover will use the simulator while feeding it with V's 
answers somewhat twisted. The ability of the simulator to simulate the interaction of the prover 
with V allows Ps get the required information to convince the honest verifier on inputs in the 
language. This means that we have an efficient prover Ps that convinces an efficient honest verifier 

V on inputs in the language and fails to convince V on inputs not in the language (by the soundness 
property of V). So we get an efficient procedure to determine if x E L and we are done. 



In order to use the simulator by the prover Ps we make some assumptions (without loss of 
generality) about the simulation, and give a convenient way of looking at the workings of the 
simulator. Our view of the simulator is especially tailored for the specific V described in the 
previous section. Recall that V invokes the honest V with a random tape R that is determined by 
hashing of the conversation so far. Also, V proceeds with an interaction only if all other concurrent 
interactions that have ended, ended accepting. 

First, we assume that whenever S generates a transcript it runs it through V. That is, before 
returning 

(^1, n, g2, ra, . . . , S2, h, Si, Ti), 

S runs V to obtain gl, sends n to V, receiving q2, and so on. Clearly, any simulator can be modified 
to perform in this manner without changing the quality of its simulation. Since our protocols are 
dialog based, we also assume without loss of generality that the simulator never sends V a value 
for ti that would cause it to reject, since it could simply compute for itself that V would reject. 

3.2.1 The proof tree 

We now turn into representing the run of the simulator S with a given verifier (and the predeter- 
mined schedule) as a tree. As it interacts with V, S implicitly generates many partial conversations, 
not all of which are successfully finished (only one need be). In generating these partial conversa- 
tions, S typically starts many proofs that may or may not be completed as the simulation proceeds. 
To discuss this interaction, we visualize these proofs using a leveled tree, which we call the proof 
tree. Each vertex v of the graph corresponds to a new m-block that has been initiated between S 
and V . A vertex v has parameters i?, g, r, corresponding to the beginning of a conversation. A ver- 
tex on level i < k may have zero or more children on level i + 1; the proof tree has at most k levels. 
A vertex v labeled Ri+i , gj+i , r j+i is a descendant of a vertex labeled i?j , g^ , r^ if the simulator runs 
V^ on a history in which V uses i?j, qi for the i-th proof, S responds with r^, V then uses i?j+i, qi+i 
to continue the interaction, and S responds with rCri- We adopt the convention that Level 1 of the 
graph is the "top" level and Level k is the bottom level. 
Whenever S runs a partial conversation 



through V , for i < k,\t may be thought of as traversing/creating the proof tree as follows. S will 
visit or create a sequence of vertices wi, . . . , f j, where Vj is on level j. First, S visits or creates the 
top level vertex vi with parameters (^i, gl, ri). The values -Ri, gi are determined by the verifier 
(according to the conversation so far, which is null) and the value fi is then determined by the 
simulator. Then, for 1 < j < ?, after visiting/creating fj-i, 5* visits/creates Vj, the unique child 
of Vj-i with parameters (i?j, ^-j fj). Again, Rj and qj are sent by the verifier and the value fj is a 
message that the simulator sends. 

Note for example, that all siblings vertices will have the same values for R and g, since they are 
all determined by the conversation so far. To avoid special cases, we adopt the convention that the 
top level vertices are siblings. Namely, we add a designated root vertex at level zero to the forest 
created so far and make it a tree by connecting the root to all level- 1 vertices. 

The second type of partial conversation simulated are those that contain also messages of type 
Si and ti. Namely, after k concurrent protocols have begun, these k protocols are being continued 



and finished. A simulated partial conversation of the form 

Ql)'l)---)Hk) 'k) "Sfc) T^k) • • • ) °i)'^i) • • • 

for 1 < i < A; may be thought of as follows. First, the simulator traverses/creates a path from 
the top level to some bottom-level vertex v, with parameters (i?^, g^, fk), of the proof tree. At this 
point, it has simulated gl, ri, . . . , g^, r^. When it runs V further, receiving Sk = s{x, R^, r^), it is 
said to activate the vertex v. When it sends an acceptable tk to V, it is said to resolve v. Note that 
by our conventions qk,rk,Sk, tk is an accepting conversation. Thus, v is resolved by the simulator 
S when S finds a message tk that convinces V to accept and proceed to sending Sk-i- When the 
simulator S receives Sk-i it conceptually activates f 's parent, and so on. S thus may be thought 
of as retracing its path back up the proof tree. The simulation may, without loss of generality be 
viewed as a series of such bounces. In general, S may retrace partially, then continue down another 
path - but insisting that S "start over" from the top level of the tree does not impair 5"s efficiency 
(by more than a polynomial factor) or correctness (since V is deterministic). 

We remark that two different nodes in the proof tree may have the same values in them. This 
may happen when two different histories result in the same R as determined by the hash function 
of V. However, these nodes are not the same. Each has a history of interaction between the 
simulator and verifier as determined by the path from the root to the vertex. This event happens 
with negligible probability because of the randomness obtained from the hash function. However, 
when this event happens, it bears no effect on the proof. 

3.3 l\irning a simulator into a prover: Overview 

We start with a high-level overview of how to convert a good simulator S into an efficient prover 
Ps- The prover Ps will run S. When S asks to question V's behavior, Ps will provide V's 
answers. Finally, Ps will use the interaction of S with V to convince the original honest verifier V 
that X e L. 

We can view our {S, V) interaction as generating and playing (not always to completion) many 
different proofs of the original protocol. On a very high level, our efficient prover Ps "splices in" 
its interaction with V into V's messages to the simulator S and uses the answers created by the 
simulator as its own. This slicing operation cannot be noticed by the simulator S since the slicing 
operation can be thought of as a random modification of the hash function: one specific value 
of going to be modified in a random manner (since the honest verifier chooses its random coins 
uniformly at random). The simulator will not be able to tell between a random hash function and 
a randomly modified hash function. 

When the honest verifier V chooses a random R and send its first challenge, q, to Ps, Ps 
conceptually alters the random hash function H so that for some set of siblings in the proof tree, 
all having parameters 

{R=iR\...,Rn,q = q\...,q'^,-), 

R^ = R for some j, I < j < m, and hence q^ = q. One of these siblings v in particular, with 
parameter (_R, q, r) will be chosen. Under the right circumstances, Ps will send V the value of 
r = r^\ great care must be taken to actually send this r to the honest verifier. This will happen later 
in the simulation, when the sliced vertex v is activated. In order to generate s; Ps will send r to V , 
receive s and splice in s^ = s. Hopefully, S will eventually resolve the vertex v and respond with 
an acceptable t; allowing Ps to forward t = P, causing V to accept. 



Any splicing attempt may have three possible outcomes: 

• Ps can succeed in making V accept, 

• Ps can fail (get stuck), losing its chance to make V accept, or 

• Ps can abort, without causing V to accept, but giving it the chance to try another slicing 
attempt. 

Nearly all the time, Ps will abort. With some small probability, Ps will succeed and with some 
(hopefully much smaller) probability, Ps will fail. We show that for most R, Ps will succeed 
more often than it will fail, and can therefore try this splicing procedure repeatedly, ultimately 
succeeding with probability at least 2/3. 

There are a number of difficulties with the above approach. First, S doesn't know R, so it can't 
really alter H as described, and will have to check exactly how it can usually simulate the behavior 
of the spliced V. A more technically problematic difficulty is that the simulator may generate many 
proofs that it never completes. Indeed, the ratio of completed proofs to uncompleted proofs may 
be quite small (though non-negligible). If Ps sends f\, to V, and S fails to generate an acceptable 
ty, Ps will not be able to cause V to accept. 

To get around the problem of incomplete proofs, we have Ps use a strategy that allows it to 
abort a splicing attempt before it has responded to V. We also have Ps choose where to insert the 
real proof into the proof tree according to a particular distribution. We show that using these two 
techniques, Ps may often abort but will only rarely fail. 

Remark: If the original proof system has negligible error, then it suffices for Ps to succeed with 
non-negligible probability. Given such an efficient Ps, one can run the proof many times to deter- 
mine whether an input x is in the language. Given an interactive proof with error bounded away 
from 1, one can run it in parallel to obtain a proof with negligible error. This gives a simpler proof 
of our theorem for this case, and can be used to extend the theorem to work for 5 message interac- 
tive proofs. Unfortunately, in the argument model, parallel amplification doesn't always work [Q], 
so we can't use this trick to obtain a general theorem. 

3.4 Splicing in the proof 

Let us first state more explicitly how the splicing operation is done by Ps when trying to prove to 
V that X G L. In the proof system, V flips coins to generate R, and generates an initial challenge 
q = q{x,R). The prover Ps reads the value q from its communication tape and invokes the 
simulator S on input x in the following manner. Ps conceptually chooses a random hash function 
H, defining V. Now Ps can simply compute H as needed on the fly. Thus, Ps can exactly simulate 
the behavior of V. Ps then runs (S, V), which starts generating the proof tree. Recall that if S 
runs through the partial conversation gi, ri, . . . , rj_i and "asks" V for the next question qi, V then 
computes its parameters R and g by 

R = H{x,i,qi,ri,...,qi-i,ri^i), and 
q = q{x,R). 

Also, recall that R and g are in fact a block of m parallel repetitions of the actual proof as the proof 
that Ps runs against the real verifier V. 



Writing R = (R^, . . . ,R^), Define splice{R,j, R) to be the m-tuple equal to R at every 
coordinate accept the jth, and R^ = R. The splice operation takes place when Ps randomly 
chooses j, I < j < m and conceptually modifies the function H on one specific value: 

H{x,qi,ri,...,qi-i,ri-i) = spUce{R, j , R) , 

and hence R^ = R. Then, conceptually, Ps just lets S continue with the simulation (we show 
below the mechanics of how Ps can do this). 

The splice operation creates a set of siblings with the above values of R and q. These are all 
the children vertices of the path in the tree whose value in the hash function has been modified. 
One of these siblings, v, may be chosen to generate the conversation with the original verifier V. 
This special sibling v is chosen at random as will be described later. 

If the special sibling v is later activated, i.e., one of its children has been solved and the sim- 
ulator expects to get V's message s in the proof represented by the vertex v, then the prover Ps 
must generate V's response s = s^, . . . ,s"\ At this stage, Ps cannot determine S^ since R^ is only 
known to V. Ps is able to determine all s^ for I < i < m and i ^ j. Thus, Ps needs to get s^ 
from its interaction with the honest verifier V. Therefore, at this specific time, Ps sends r = r^ to 
V, receives s and sets s^ = s so that it can continue the run of the simulator. 

Here is where Ps suffers from not knowing R, which would allow Ps to compute s^ by itself. 
It uses V to perform this computation for it, but note that this trick may be performed only once 
(and at great risk). Once Ps gave the honest verifier a message r and got its response s, it is not 
possible for Ps to change its mind and send V a different message r'. The honest verifier does not 
agree to such "rewinding" of a proof. Ps cannot waste this try it on a sibling of v, since it needs 
this try to activate the vertex v. So, if a sibling of v is activated before v is activated, Ps aborts. 
Note that in this case, Ps has a chance to try again, since no r has been sent to the honest verifier 
V, and V is still waiting for such an r to appear. Trying again means randomly choosing a new 
H and a splice index, and starting a new simulation with S from scratch. The case that Ps fails 
completely is when a sibling of v is activated after v is activated. In this case, Ps has sent V the 
message r, but is required to respond to the simulator on another sibling, namely, a different r. If 
that happens before the simulator resolves v, then Ps cannot proceed. We assume in a worst case 
manner that if a sibling of v is activated, then Ps fails. We announce this failure even if the sibling 
is activated before v, or even if the sibling is activated after v has already been resolved. 

If S resolves v, generating a value of t = t^, . . . , t™ that will cause the spliced V to accept, 
then Ps sends ttoV. At this point, Ps succeeds in convincing the honest verifier V (Here we use 
the fact that S only sends an acceptable t). 

Except for choosing where to splice in the proof, we have specified Ps. It can be verified that, 
at least up to the point where Ps aborts, Ps perfectly simulates the behavior of V with the spliced 
H for the simulator. Namely, the view of the simulator S in case it gets V (with a randomly chosen 
H) as a black box is identical to the view of the simulator in case it is invoked by Ps with a spliced 
V. 

3.5 Choosing the spliced vertex v 

We define the height of a vertex at level i to he h = k — i + I. Namely, a vertex that represents 
the first proof in the schedule has height k and a vertex representing the A:-th proof in the schedule 
has height 1. Our method for choosing which special vertex v to splice in the conversation with V 
obeys the following design criteria: 



• The probability that a generated vertex v is the special one depends only on its height, and is 
completely independent of any other aspect of the entire run of S. 

• \iv has height h, it's probability will be proportional to f{h), for some carefully chosen /. 

First, let us bound the running time of the (average) polynomial time simulator. Let n = \x\ 
and let a be a constant such that S runs in an expected number of steps at most {nkm)°'. Since 
P always causes V to accept, S must cause V to accept (that is, generate a path going all the way 
down and then all the way up the proof tree) with probability close to 1. By Markoff's inequality, 
if we only allow S to run for N = 100(nkm)°' steps, it will still succeed with probability greater 
than 0.9. Indeed, its simulation will no longer be close to the actual one, but, our analysis will only 
consider whether S causes V to accept. For the rest of the analysis, S will only run for N steps. 

With S as above, every level has at most A^ vertices. We use the following addressing scheme 
for the vertices of the proof tree. As discussed in Section |3.2.1| , we imagine a dummy root vertex 
at Level that has all the Level 1 vertices as children. For each vertex v generated on level i 
we keep track of how many vertices have been generated on the same level before v. To each 
vertex v we assign an address (i, a), denoting that v is on level i and is the ath vertex generated 
on level i. Note that the content of an address is a random variable determined by the run of the 
simulator with V. In particular, it is possible that at some level i there will be less than A^ vertices 
and thus an address will not correspond to any actual vertex generated in the proof tree. However, 
each vertex that is actually generated has an address (i, a) with 1 < i < h and 1 < a < A^. To 
choose the special vertex v for the splicing, we choose the address of v at random by first picking 
a level i with probability cf{h), where h = k — i + 1 and c is the normalizing constant defined by 
J2h=i cf{h) = 1, and choosing a uniformly subject to 1 < a < A^. Thus, any address of height h 
is selected with probability cf{h)/N. 

The precise function / is a polynomial f(h) = h^ chosen to make the analysis work out; we 
defer the determination of [3 to that section. Note that this choice puts a higher probability weight 
on higher vertices. 

4 Preliminary analysis of the splicing operation 

We now bound below the probability that Ps succeeds and the ratio of the probability that Ps 
succeeds to the probability that Ps fails when R is chosen uniformly. As discussed later, this is not 
sufficient to prove our theorem, but is a very good start. We begin with formalizing the fact that the 
simulator S cannot tell if (and where) the proof tree is being spliced. Then, we relate properties of 
the proof tree with the probability that the simulator succeeds or fails, and finally, we bound these 
probabilities by bounding probabilities of events that are related to the generation of the proof tree 
by the simulator. We first consider the following experiment. 

Experiment 1: Execute the following steps: 

1. Choose a random address (z, a) as above. 

2. Choose R uniformly (over strings of the appropriate length) and run V with R. 

3. Generate and traverse the proof tree by running S against V with a randomly chosen H, 
choosing (z, a) as the address of the special vertex t>, and splicing accordingly. 



4. Output the traversed tree, the order in which the vertices in the tree were generated/traversed, 
and {i,a). 

Since we output the proof tree and the order in which vertices are generated/visited, we can de- 
termine which vertex is (i, a), and for each vertex we can determine whether it has been activated 
or resolved. We also assume, for the sake of the analysis, that the simulation continues even if Ps 
fails. That is, once we splice the game in, we allow Ps to query the honest verifier V multiple 
times. Of course, we have to take into account the fact that Ps really failed in this case. 

Definition 2 Given a run of the simulator with a verifier V, we define the following properties of 
an address {i, a) in the run of Experiment 1. These properties depend on the random coins of the 
simulator and V 's messages. The messages of V, in turn, depend on the random H that it uses, 
the spliced address {i, a) and the random coins of the real verifier R. 

1. We say that an address {i,a) in the output of experiment 1 is good iff the vertex at that 
address is resolved and no sibling vertex is ever activated. 

2. We say that an address {i, a) is bad ijfthe vertex at that address is activated but not resolved 
or if any sibling vertex is ever activated. 

3. We say that an address {i, a) is interesting if it is either good or bad. 

4. We say that a vertex v is good/bad/interesting if its address in the given run is good/bad/interesting. 

The following lemma follows from the construction of Ps and the definitions. 

Lemma 2 The probability that Ps succeeds in convincing V is at least the probability that the 
chosen address {i, a) is good with respect to the run of S against the spliced V. The probability is 
taken over the random tape of S, the choice of {i, a) for the slicing, the choice of the function H 
determining V 's messages, and the random tape R of V. The probability that Ps fails is bounded 
above by the probability that (i, a) is bad with respect to the run of S against the spliced V. 

We now formalize the fact that the simulator cannot tell whether the interaction with V has 
been sliced or not. Recall that when R is chosen uniformly, all the splicing operation does is con- 
ceptually replace a uniformly chosen value (of the hash function) with another uniformly chosen 
value. This is exactly the case for us, since the simulator cannot ask enough questions to tell that 
H is not completely random. It asks at most N questions and H is A^-wise random. It follows that 
the splicing of {i, a) using the original verifier V yields the same distribution on the run of the sim- 
ulator (and thus, on how the proof tree is generated and traversed) and this distribution is exactly 
the same as if we never spliced in a game. We can therefore reorder the steps of the experiment as 
follows. 

Experiment 2: Execute the following steps: 

1 . Generate and traverse the proof tree by running S against V with a randomly chosen H (with 
no splicing). 

2. Choose a random address {i, a) as above. 



3. Output the traversed tree, the order in which the vertices in the tree were generated/traversed, 
and {i,a). 

Note that the notion of being activated and resolved is simply a property of the tree genera- 
tion/traversal, and is therefore still well defined. We will now associate success and failure of the 
simulator with the type of vertices in the proof tree. Lemma |] follows from the above discussion 
and a straightforward application of Bayes theorem. 

Lemma 3 The probability that Ps succeeds is bounded below by the probability that the output 
{i, a) is good with respect to the tree output by Experiment 2. Here the probability is taken over the 
random tape of the simulator S, the choice of {i, a) for the output, and the choice of the function 
H determining V 's messages. The probability that Ps fails is bounded above by the probability 
that the output of Experiment 2 satisfies that the output {i, a) is bad with respect to the proof tree 
in the output. 

The event that the output (i, a) is good with respect to the output tree is equal to the sum over 
all good addresses (i', a') in the tree of the probability that (i, a) = (i', a') (and similarly for the 
probability that (i, a) is bad). We can thus recast Lemma ^ as the following calculation. Consider 
the random variables SUCCEED, FAIL and INTERESTING, generated as follows. An H is chosen at 
random for V, and then S (on a uniformly chosen random tape) generates and traverses the proof 
tree, and finally, it outputs the proof tree and we compute 

SUCCEED = Yl cf{k - i + l)/N, 

(i, a) good 

FAIL = Y. cf{k-i + l)/N and 
(i, a) bad 

INTERESTING = ^ cf{k - i + l)/N. 

{i, a) interesting 

Note that interesting = succeed + fail. We will bastardize terminology slightly, and 
speak of these variables after a given generation/traversal of a proof tree. 

Lemma 4 The probability that Ps will succeed is at least ^'(succeed) and the probability that 
Ps will fail is at most ii^(FAlL). The expectation is taken over the choice of the random tape for the 
simulator and the hash function H for V . 

To bound these expectations, we need to consider the structure of good and bad addresses. 

4.1 The structure of bad and good addresses 

Recall that a property of the verifier V is that it does not carry on with any of the proofs once one 
of them fails. Thus, V will never provide its second question (i.e., the third message of the proof) 
for a level-i proof for z < A; unless one of its children (in the proof tree) has been completed and 
V accepts. As a consequence, any interesting (good or bad) vertex has to have a child vertex that 
is resolved (and also interesting). This is the main restriction that makes the life of the simulator 
difficult. It cannot get the verifier's third message of protocol j + 1 before it has resolved protocol 



j, i.e., it has produced an answer that is convincing the verifier for protocol j. We phrase this 
restriction as a combinatorial property of the interesting (good and bad) addresses. We start by 
defining a snake. Loosely speaking, this is a path in the tree that goes down to a leaf. 

Definition 3 A snake a is a series of vertices 

such that Vj is on level j and f j+i is a child of Vj for i < j < k. We call vi the head of a and 
f j+i, . . . ,Vkthe body of a. We define the height of the snake h{a) to be k — i + 1 (this is the length 
of the snake and the height of its head). 

Lemma 5 For any generation/traversal of a proof tree by the simulator together with any V, the 
set of interesting vertices can be canonically decomposed into disjoint snakes such that 

• Ifa vertex is a bad vertex with no bad siblings then it must be a head of one of the snakes. 

• Given a set of bad siblings, at most one of them is in the body of a snake. The rest of the bad 
siblings must be heads of snakes in the decomposition. 

Proof: Given a proof tree we build the set of snakes in the following manner. From each interesting 
vertex v without an interesting parent, we start a snake, with v as the head. If v is on level k we're 
done, else v must have at least one resolved children, thus, it has at least one interesting child. In 
some canonical fashion, choose one of the interesting children to recursively continue the snake, 
and start new snakes at the other interesting siblings. 

The properties required by Lemma || are easily verified: If a vertex is bad, then it is either 
activated but has activated siblings or it is activated but not resolved. Suppose the second case 
holds and the first does not. Then it is a bad vertex with no bad siblings. In this case, since the 
vertex has not been resolved, the verifier V has not activated its parent and this is an interesting 
vertex with no interesting parent. Thus, this vertex is a head of a snake as required. Suppose the 
first case holds, i.e., several siblings have been activated. If their parent is not interesting then all of 
them are heads of snakes (and no one is in a body of a snake). Otherwise, the parent in interesting 
and one of them at most is chosen to continue the parent's snake, whereas the rest are snake heads. 
Thus, again, at most one of these siblings is in the body of a snake as required. □ 

We would like to use this structure of good and bad vertices to show that the probability of 
choosing a bad vertex in the output is smaller than the probability of choosing a good vertex. We 
note that most of the bad vertices are heads of snakes. Actually for each bad vertex that is not a 
head of a snake, there exists at least one sibling that is a head of a snake. On the other hand, the 
interesting vertices are all vertices in all snakes. We will show that the weight of bad vertices is 
much smaller than the weight of interesting vertices. Thus, the weight of good vertices (interesting 
but not bad) is high enough. 

Given a canonical snake decomposition of the interesting vertices of a graph, we can bound 
FAIL and INTERESTING as foUows. Let F{i) = J2]=i /(«)• 

Lemma 6 For any proof tree output by experiment 1 or 2, 

FAIL < 2Y,cfih{cr))/Nand 

a 

INTERESTING > ^cF{h{a))/N. 



Proof: To establish the bound for fail, note that cf{h{a))/N is simply cf{k — i + l)/iV, where i 
is the level of cr's head. By Lemma ^ A lone bad vertex (without a bad sibling) must be at a head 
of a snake and is therefore counted in the summation. By Lemma ^ given a set of bad siblings, all 
of them but one are heads of snakes and are thus counted. The worst case of undercounting the bad 
vertices is when there are exactly two bad siblings of which one is the head of the snake but the 
other isn't. However, this undercounting is compensated by the 2 in front of the summation. This 
establishes the bound for BAD. To establish the bound for INTERESTING, note that cF{h{a))/N 
simply sums the contribution of each vertex in the snake. Since the snakes are disjoint, the weight 
of all interesting vertices is the sum of weights of all vertices in all snakes. □ 

The above lemmas connect the snakes decomposition to the weight of good and bad vertices. 
Each snake decomposition satisfies these requirements. We would like now to go on and show 
that there is higher weight on good vertices than on bad vertices when the simulator succeeds in 
outputting a conversation. We will first note that long snakes are good for us, and then note that all 
the short snakes are overshadowed by one full snake of a successful simulation. 

4.2 Setting the parameters 

We first set A; = |x| , i.e., the number of block proofs run by the schedule is the length of the input. 
We choose the number of parallel proofs in each proof block to be m = k^. Recall that A^ is a 
bound on the running time of the simulator, which is polynomial in the length of the input. We 
choose (3 to be around the degree of a that polynomial. Specifically: [3 = 1+ \\og^^{N)'\ . Finally, 
we set f{h) = h^ , and thus c, the normalizing factor, is c = 1/ (l]h=i h^j ■ It is easy to verify that 
for any h and any positive integer (3, F{h) > h^+^/{(3 + 1), and hence F{h)/f{h) > h/{(3 + 1). 

We would like now to distinguish long snakes (which will be good for us) from short snakes 
(which will be dominated by the long ones). 

Definition 4 We say that a snake a is short ifh{a) < 10(/9 + 1) and long otherwise. 

Using Lemma || and the fact that F {h{a)) / f {h{a)) > 10 for a long snake a, we have 

INTERESTING > ^ cF{h{a))/N 

long a 

> 5 E 2c/(Ma))/iV 

\long a I 

> 5 [fail- Y. '^cf{h{a))/N 

V short a 

> 5 [fail- Y. 2c(10(/3 + l))^/A^ 

V short a 
[Since a is short] 

> 5(fail-2c(10(/3 + 1))^) 



The last inequality follows because there are at most A^ snakes in the decomposition. Summing 
up, we get: 

fail < interesting/5 + 2c(10(/? + 1))^. (2) 



Now, if the constant term were 0, this would imply that we succeed much more than we fail, 
since interesting = succeed + fail. We would like to show that the constant term is small 
comparing to interesting and we will do that by using the fact that there is a long snake: the 
one that is output by the simulation. However, the long snake appears only if the simulation ends 
well. So we need to compute the expected value of the constant term over the random coins of the 
simulator. Recall that it succeeds with probability at least 0.9. By the linearity of expectation we 
get that for any value of H determining the behavior of V, 

E{fail) < E(interesting)/5 + 2c(10(/3 + 1))^. (3) 

Where the expectation is taken over the random coins of the simulator running against the fixed 
verifier V. We now show that the constant term is small comparing to ^'(interesting). 

Lemma 7 Fix a hash function H and a corresponding verifier V, then 

2c(10(/3+ 1))'^ < E(interesting)/10, 

where the expectation is taken over the random coin tosses of the simulator 

Proof: Recall that the simulator must work on x E L against any possible verifier V. Note also 
that in the original interaction V is always convinced by the proven Thus, with probability at least 
0.9, S succeeds in finishing all k games and then there is a snake of height k (from the bottom to 
the top). Also, recall that /3 was set so that N < k^^^; therefore: 

E(interesting) > 0.9cF{k)/N 

k^ 
> 0.9c—— = 0.9ck 

kP~^ 

For sufficiently long inputs (and thus sufficiently large /c's), 0.9A; is greater than the constant 
20(10(/3+l))^andwearedone. □ 

Finally, Lemma |] follows from Lemma 0, Equation ^ and the fact that c is a polynomial fraction 
in k. 

Lemma 8 Ps succeeds with probability at least l/k'' for some constant 7. Furthermore, Ps suc- 
ceeds at least 4 times as often as Ps fails. 

5 Showing success for most R 

Naively, one might suppose that Lemma |8| would imply that we are done. Given an input x E L, 
Ps keeps on trying the splicing strategy (with the parameters determined above) until it succeeds or 
fails. It will conclude in expected polynomial time and it will succeed with probability at least 4/5, 
implying that L E BPP. However, this analysis would only hold if V chose R independently for 
each of Ps attempts; in reality, V chooses R once. The problem is that the previous section bounds 
the expected success rates over a random simulator coin, and thus over a random R. Also, note that 
it is possible that only a small fraction of the vertices traversed by the simulator are interesting, and 
the simulator has some control over which of them are. So if we only have Lemma ^ it is possible 
that for a very small fraction of R, Ps succeeds much more often than it fails, yet for the rest of 
the R, Ps fails a bit more often than it succeeds. Thus, Lemma || is not enough. 



We now use the parallel repetitions to finish the proof. Recall that each vertex in the proof 
tree corresponds to a block ofm = k^ parallel copies of the original proof. Out of these m = k^ 
original proofs at most one is altered by the splicing operation. Loosely speaking, we exploit this 
fact to show that the conditioning over one random entry in such a big block of proofs is, in a 
way, unnoticable and the chances of hitting a good vertex, even when R is "almost fixed" is still 
higher than the chances of hitting a bad vertex. More formally, we will show that for nearly all R, 
the success and failure probabilities are close to the expected values over the random tape of the 
simulator as stated in Lemma |[ 

Lemma 9 For all but measure .01 of the random strings IZ, Ps succeeds with probability ^ far 
some constant 7. Furthermore, far all but measure .01 of the random strings TZ, Ps succeeds at 
least 3 times as often as Ps fails. 

Remark: By setting parameters correctly, the 3 can be replaced by anything less than the corre- 
sponding value in Lemma |^. In turn, this value (set arbitrarily at 4) can be set to any constant (or 
indeed, can be polynomially large, with care). Similarly, the .01 may be made arbitrarily (though 
non-negligibly) small. 



We will prove Lemma |^ using Lemma [l^ and [TT| below. But let us first explain why Lemma ^ 
is sufficient for proving our result. 

Proof of Theorem J: As described above, we build a simulation based prover Ps that can convince 
the honest verifier to accept with probability 2/3 on x G L. For x ^ L Ps convinces V with 
probability at most 1/2 by the soundness property of V . Thus we get a probabilistic polynomial 
time algorithm to determine L: Run Ps against V and accept iff V accepts. Since both Ps and V 
are efficient, this can be done in polynomial time. 

It remains to show that Ps succeeds with probability 2/3 when x E L. We use Lemma ^. With 
probability .02 a bad random tape is chosen for V and then Ps looses. But if V chooses a good 
random string, the Ps will succeed in the following procedure. 

Choose uniformly at random a random tape for the simulator and a hash function H. Run 
the simulator against the verifier V with the chosen H, while splicing the real interaction with 
V into the interaction of the simulator with V as described above. By Lemma ^, Ps succeeds 
with probability p > -^, fails with probability q < p/3 and gets another chance with probability 
1 — p — q. Thus, the simulator can repeat the experiment for k^^ times unless it fails or succeeds. 
Success happens with probability at least 2/3 as required. □ 

It remains to prove lemma ^. We start by showing that if one random entry in an m-length 
random i?'s vector is modified to contain a random R chosen out of a small (but not too small) 
subset of the -R's, then this doesn't affect the distribution space too much. Let 7^ denote the set of 
V's possible coin tosses and TZ' denote an arbitrary subset of TZ of measure at least .01 (that is, a 
uniformly chosen R is in TZ' with probability at least .01). Let D denote the uniform probability 
measure on 7^"* and let D' denote probability measure obtained by choosing (R^, . . . , R"^) uni- 
formly, choosing j, I < j < m uniformly, and then replacing R^ by a uniformly chosen element 
of 7^'. Lemma [T^ says that these measures are multiplicatively close over most elements of their 
domain. 

Lemma 10 For all R's except for a negligibly small measure (over both D and D') it holds that: 

(1 - ^)PrD{R) < PrD'iR) < (1 + l)PrD{R). 



Proof: Suppose that R has £ elements in TZ' and let p denote the measure of TZ' under the uniform 
measure. By an elementary probability argument, we can explicitly derive the relevant probabili- 
ties, obtaining 



\m-i 



ProiR) = ^V^ m^i . and 



PrD'iR) 



Thus, we have 



m|7^'H7^|™-^ 



m—i 



Thus, the inequality of Lemma [T^ holds as long as 



(1 - -)pm < ^ < (1 + -)pm. (4) 

k k 

It remains to bound the probability that i deviates significantly from pm. But note that by the dis- 
tribution D this is just the tail of the Binomial distribution and can be bounded using the Chernoff 
bound. Recalling that m = k^ and that p > 0.1 , we get that Equation ^ holds with probability 
close to 1 (up to an exponentially small (in k) fraction) under the distribution D. It remains to note 
that D' deviates from D by at most one entry. Thus, the difference in the value of i is at most 1, 
and thus Equation ^ holds under D' with essentially the same probability. □ 

Definition 5 We denote by B the set of negligible measure of random tapes Rfor which Equation 
does not hold (and thus, the guarantee in Lemma ^ does not necessarily hold). 



We go on and show a similar result which is more specific to our setting. We define two 
probability spaces over the hash functions. The first distribution is the uniform distribution over 
all i/'s in the family and we denote this probability space by Ti. The second set of distributions 
is indexed by an address (i,a), a random tape s for the simulation, and a set IZ' . We denote 
this distribution by and denoted l-i{i,a,s,TZ') depends on the behavior of the simulator and on 
any arbitrary predetermined set of random coins TZ' of measure at least .01. It is defined by the 
following sampling procedure. 

• Choose H by Ti. 

• Choose an index I < j < m uniformly at random. 

• Choose R E TZ' uniformly at random. 

• Run the simulator S on the random tape s with the black box being the verifier V with H. 
If a vertex (i, a) appears, modify one entry in H so that vertex (i, a) contains R in its j-th 
location. Output the resulting H. Otherwise (if a vertex at address (i, a) does not appear), 
output H with no modifications. 



All above random choices are independent of each other. 

Note that if we fix a random tape s to the simulator S and a hash function H, then the proof 
tree is fixed. Also, for each given s, if H is chosen uniformly at random, then the probability 
that the proof tree includes a random tape R E B is negligible. This is because the tree contains 
a polynomial number of -R's, which, for a random H, are selected uniformly at random. Denote 
the set of such pairs {H, s) that have an R E B in their proof tree by C. The set C has negligible 
probability to be picked when s and H are uniformly chosen. But note that this set also has 
negligible probability when H is chosen under 7i(z, a, s, TZ') for any possible z, a, s. In all vertices 
except for the modified (i,a), H E 'H{i,a,s,TZ') behaves uniformly. And at the vertex (i,a) 
only one entry out of the m gets modified. So the probability that the resulting ^ is in S is still 
negligible. 

Lemma 11 For any TV of measure at least .01 and for all pairs {H, s) not in C it holds that for all 
addresses {i,a), 1 < i < k and 1 < a < N, 

(1 - l)Prn{H) < Prni_.,a,s,n'){H) < (1 + \)Prn{H) 

Proof: We concentrate on the right Inequality in Lemma [iT]. The left Inequality follows in the same 
manner. If (i, a) does not appear in the interaction of Ss with Vh, then Pr'n{i,a,s,n')iH) = Pr-niH) 
and we are done. (Note that the modification of H at address (i, a) in the sampling procedure of 
H^i, a, s, IZ') does not make address (i, a) appear or disappear from the proof tree.) Suppose (i, a) 
does appear in the proof tree traversed by Vh with Ss, and consider the sampling procedure of 
?i(z, a, s, IZ') . First, a function H is chosen by Ti, and then if the entry (z, a) appears in the run of 
Vh with Ss then a random entry 1 < j < m is chosen in that vertex and a random R' is chosen 
in IZ' and then the hash function is modified so that its value at vertex (z, a) contains R' in the jth 
entry. Denote by -Rj ^ the vector R that appears in vertex (i, a) before the modification with the 
newly chosen R' . We may write the probability of choosing an H through this procedure by: 

PrH{^,a,s,n'){H) = Y. Prn{Rr,a = R) " Prn(i,a,s,n'){H I R^,a = R) (5) 

ii 

Let us now bound Pr'}^{i^a,s,'R.'){H \ Ria = R)- First, if vertex (z, a) in the interaction of Vh with 
Ss is different from R in more than one entry, then this probability is zero. What is the probability 
that a specific function H is sampled by 7-^(i, a, s, IZ') given the Ria = -R? It is the probability 
that all the entries other then (z, a) were chosen as H and that R was modified to fit our H. Let us 
compute this probability by summing over all choices of iJ's (by 7i) and j's that may have led to 
picking this hash function. Note that once H and s are fixed up to one change in a specific vertex, 
the string on which H is modified is also determined. Let this entry be a and R is H'(a) for H' 
that was picked by H before the modification. Let V^H, a, j) be the set of H's that have the same 
values as our H on all entries expect at the jth index on input a. The cardinality of ViH, a, |) is 
exactly |7^|, the number of possible values that R may take. 

Prni.,a,s,n')iH \ R.,a = R) = E - " p^ " E P^H') 

j:RjeTl' II H'eV{H,a,j) 



Since the probability of all possible H's are equal in H, we get: 

\n 

m \TZ' 



Prni^,a,s,n'){H\R,,a = R) = - ■ ^^ ■ Prn{H) 



where i is the number of indices I < j < m satisfying that R'j E 71'. Now, since the pair (if, s) 

PrniH) (6) 

R) ■ PrniH) 



is not in C, 


then R' is not in B,soi<{l + l)m^-^. 


and 




Prn{i,a,s, 


Tl'){.H Ri^a — R) 


^(-1 


Using Equation || in Equation ||, 


we get: 






PrniH) < 


R 


,a,s,'R.')iRi,a 




< 


(1 + i) . PrniH) 





and we are done with the right inequality of Lemma |rT| The left inequality follows from the 
symmetric counterpart of Equation ^ and we are done with the proof of Lemma [IT]. □ 

Proof of Lemma 0: We start with the first part of Lemma ^. Let TZ' be an arbitrary set of measure 
at least .01 in 7^ and suppose that if R is randomly and uniformly chosen in 7^ then the probability 
of getting a good vertex for the splice in Experiment 1 is at least l/k"' (as guaranteed by Lemma 
|8|). We will show that the probability that Ps succeeds with the verifier choosing its coin tosses 

i?G7^'isatleast^Ti7. 

lOU fe ' 

Recall that for a "normal" uniformly chosen R E TZ, we can check the probability that Ps 
succeeds by choosing H according to H, choosing a random tape for the simulator uniformly, 
choosing a random (i, a) with probability n^ ^^ above, and checking if (i, a) is a good vertex 
in the proof tree of Vh and Sg. The difference now is that R is chosen from the set 7^' and so in 
order to compute the probability that the simulation based prover Pg succeeds, we must think of 
the following experiment. An address (z, a) is chosen as above, a random tape for the simulator s is 
chosen uniformly, H is chosen according to H, j is chosen uniformly between Itom, R is chosen 
uniformly in 7^', and then we run Ps against Sg with Vh with R spliced into the vertex (i, a) at 
index j. Alternatively, we may think of this probability as choosing uniformly independently at 
random s and (i, a), then choosing H according to 7i(z, a, s, 7^'), and finally, checking whether 
(i, a) is good in the interaction of Vh with Sg. Let /(s, H, i, a) be an indicator variable indicating 
if the vertex (i, a) in the interaction between Ss and Vh is good. Using this notation with R being 
randomly chosen from TZ as in Lemma |]the probability p that the simulation based prover succeeds 
satisfies: 

p = EE '^^'y^'^ E ^E^-^(^K(^,^,^,«) > ^- (v) 

i=la=l ^^ s6{o,l}l''l H 

Now, to switch to R being chosen in 7^' we rewrite the probability of choosing H in the above 
formula. The probability, p', that the simulation based prover succeeds may be written as: 

P' = EE '^^^y^^^ E ^^T.Pm..s,n')iH)Iis,H,z,a) (8) 

i=la=l sg{o,l}l = l H 

> EE '^^^V^^^ E :^^■Prni^,a,s,n')iH)■Iis,H,^,a) 

i=l a=l ^^ (s,H)^C '^ 



We only have pairs (s, H) that are not in C in the summation, and thus, we may apply Lemma [TT 



to relate the probability of picking H under 7-^ (i, a, s, IZ') to the probability of picking H under Ti. 

V' > (1-h-EE '^^'y^'^ E ^,■Prn{H).Iis,H,^,a) 

1^ i=la=l ^^ {s,H)<^C^ 

Now, since the measure of all (s, H) E C h negligible, we may add back C to the summation and 
subtract some negligible fraction e: 

p > (i-^)-EE^^^^^^i^E^-^-«(^)-n^,^,^,«)-^ 

,^ l^ 99 1 

= (1- -) -n - e > — 

^ k' ^ - 100 fc^ 

and we are done with the first part of Lemma ^. To show that the second part holds as well, we 
need to show that the upper bound on the bad vertices is also close to the one given in Lemma ^. 
To show this, we define pbad instead of p in Equation ^ to represent the probability that we get a 
bad vertex when R is chosen uniformly. We then define p^^^, to represent the probability that we 
get a bad vertex when R is chosen in IZ' , instead of p' in Equation ^. In order to remove pairs 
(s, H) ^ C from the sum while giving an upper bound, we compensate on the removal by adding a 
negligible fraction e. Here, we rely on the fact that C is negligible also when H is chosen according 
to H{i, a, s, TV). Using Lemma [TT] again to relate the probability of picking H under 7i(i, a, s, TV) 
to the probability of picking H under H.. We get in the end that p[^^ is at most (1 + |) ■ P + 2e, and 
so p[g^^ < Y^ ■ Pbad and we are done with the proof of Lemma ^. □ 
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